Dynamic interface binding using XML transformations

ABSTRACT

An improved Extensible Style Language Transformations (XSLT) processor adapts to dynamic environmental conditions of a target platform on which the XSLT processor operates. Based on the dynamic environment condition(s) of the target platform, the XSLT processor, using an Extensible Markup Language—Remote Procedure Calling (XML-RPC) source document and an Extensible Style Language (XSL) stylesheet, generates customized script that accomplishes the directive of the XML-RPC source document.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to the field of computersoftware, and in particular to Extended Markup Language (XML) datatransformations. Still more particularly, the present invention relatesto an XML data transformation technique that allows the dynamicgeneration of software components based on runtime factors, such asenvironmental conditions, policy, and other dynamic characteristics, ofa target platform.

2. Description of the Related Art

Interface binding, or the process of linking discrete softwarecomponents together using predefined interfaces, is critical to everyaspect of software development. Interface binding usually involvespredefined and unambiguous interface definitions. The interfacedefinitions represent a contract between a first software component (thecaller) and a second software component (the callee). This contractspecifies the format and behavior of the interface in unambiguous terms.Once specified, the interface must comply with its contract, which meansthat the interface cannot change, either in definition or behavior.

The modularity of a software component frequently depends upon thenature of its interface binding technology. Generally speaking, thelonger a software component can delay binding to the interfaces ofanother software component, the more modular that software component canbe. “Late binding” is the term used to describe the technique ofpostponing of interfaced binding to the last possible instant.

One common interface binding is described in the “XML-RPCSpecification”, by Dave Winer, published by UserLand Software, Inc.,Jun. 15, 1999, which is herein incorporated by reference in itsentirety. XML-RPC, which stands for “Extensible Markup Language—RemoteProcedure Calling,” is a specification and set of implementations thatallow software running on disparate operating systems on two separatecomputers to exchange procedure calls over the Internet. HyperTextMarkup Language (HTML) is used to transport the calls, and ExtensibleMarkup Language (XML) is used to encode the call at each of the twocomputers.

Although XML-RPC is able to communicate across different operatingsystems, XML-RPC is confined to responses that are fixed according tothe (HTML-XML) interface between the two XML engines. That is, althoughXML-RPC allows a first computer system to evoke a procedure call on asecond disparate computer system, XML-RPC alone does describe a callprocedure that is based on dynamic factors, such as environmentalconditions (e.g., temperature, device status, load, etc. in thecomputer), policy (business logic, identity, service level agreement),or other dynamic characteristics of second disparate computer system.

What is needed, therefore, is a method for tailoring which procedurecall (or other software component) is made on a second computer systemby a first computer system, such that the procedure call is determinedby dynamic factors, such as environmental conditions, policy, or otherdynamic characteristics of second disparate computer system.

SUMMARY OF THE INVENTION

The present invention is thus directed to an improved Extensible StyleLanguage Transformations (XSLT) processor that adapts to dynamicenvironmental conditions of a target platform on which the XSLTprocessor operates. Based on the dynamic environment condition(s) of thetarget platform, the XSLT processor, using an Extensible MarkupLanguage—Remote Procedure Calling (XML-RPC) source document and anExtensible Style Language (XSL) stylesheet, generates customized scriptthat accomplishes the directive of the XML-RPC source document.

The above, as well as additional purposes, features, and advantages ofthe present invention will become apparent in the following detailedwritten description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further purposes and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, where:

FIGS. 1 a-b depict a prior art conversion of an XML document into anHTML document;

FIGS. 2 a-b illustrate the present invention's use of a modified XSLTprocessor to create script from an XML source document and an XSLstylesheet based on current environmental/dynamic conditions of a targetplatform;

FIG. 3 depicts a process in which an XML-RPC response document can begenerated;

FIG. 4 illustrates the use of the present invention to generate binaryexecutable code;

FIGS. 5 and 6 depict the use of the modified XSL processor to selectwhich XSL stylesheet to use with an XML-RPC source document; and

FIG. 7 illustrates an exemplary computer system in which the presentinvention can be implemented.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures, and in particular to FIG. 1 a, ablock diagram of a prior art transformation process using an XSLTprocessor 102 is shown. XSLT processor 102 combines information from anXML source 104 and an XSL stylesheet 106 to create an HTML document 108.

HTML is an authoring language used to create documents on the World WideWeb. HTML defines the structure and layout of a Web document by using avariety of tags and attributes. (Incorporated by reference herein in itsentirety is the HTML specification found in “HTML 4.01 Specification W3CRecommendation 24 Dec. 1999”, published by the World Wide Web Consortium(W3C).)

Both a strength and limitation of HTML are that HTML uses a fixed set ofconcepts (such as paragraphs, lists, and tables) to create a webpage.Thus, the elements in HTML are essentially typographic. While thisfeature is useful in creating unambiguous code, it is often not “realworld” friendly.

A language that is very “real world” and user friendly is the ExtensibleMarkup Language (XML), which was defined in early 1998. (Incorporated byreference herein in its entirety is the XML specification found inExtensible Markup Language (XML) 1.0 (Third Edition), W3CRecommendation, 4 Feb. 2004, Francois Yergeau, Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Male.)

XML is a markup language used to represent structured contentindependent of its presentation. Specifically, XML describes a class ofdata objects called XML documents. XML documents are made up of storageunits called entities, which contain either parsed or unparsed data.Parsed data is made up of characters, some of which form character data,and some of which form markup. Markup encodes a description of thedocument's storage layout and logical structure. and partially describesthe behavior of computer programs which process them.

Unlike HTML, the tags used in XML markup are entirely user defined, withthe intention being that these tags should relate to objects in thedomain of interest (such as people, places, prices, and dates). Thisflexibility creates problems in displaying content, however, since thereis a lack of fixed formatting instruction in an XML document.

To allow an XML document to be visually displayed using HTML, there mustbe an interface binding between the XML document and the HTML document.This interface binding occurs in two steps: transformation andformatting. That is, the XML document must first be transformed into anHTML document, which can then be formatted by an HTML browser(formatting engine). A language that has been developed to transform theXML document into HTML is the Extensible Style Language Transformations(XSLT) language, which was developed by the World Wide Web Consortium(W3C) and published as a Recommendation specification on Nov. 16, 1999.(XSL Transformations (XSLT), Version 1.0, published as W3CRecommendation 16 Nov. 1999, James Clark, Editor, and available athttp://www.w3.org/TR/1999/REC-xslt-19991116, is herein incorporated byreference in its entirety.)

With reference now to FIG. 1 b, there is depicted pseudocode used by andresults of the process shown in FIG. 1 a. XML source 104 provides asource of data to be used to populate the HTML document 108. In theexample shown, XML source 104 has “Dynamic Interface Binding Using XMLTransformations” in a “title” field, and “Michael Day” in an “inventor”field. These fields populate the corresponding fields shown in the XSLstylesheet 106, to create the HTML document 108 as shown. The HTMLdocument 108 is displayed in a Graphical User Interface (GUI) 110 asdepicted.

The process described in FIGS. 1 a-b requires predefined staticinterface definitions. Using such static interface definitions, a firstsoftware component (XML document) can only integrate with a predefinedset of another software component (HTML document), and then only usingpredefined interactions described in prior art XSLT processors.

With reference now to FIG. 2 a, an overview of the broad concept of thepresent invention is presented. In a target platform 200 (a specificallyhardware-configured computer system running a particular operatingsystem), an improved XSLT processor 202 combines an XML source 204, anXSL stylesheet 206, and one or more dynamic environmental conditions 208of target platform 200, to generate a script 210. Preferably, the XMLsource 204 is generated by and transmitted from a management application212, such as a remote manager. In a preferred embodiment, XML source 204is an XML-RPC source document. It is significant to note the followingitems.

First, the dynamic environmental conditions 208 may be either softwareor hardware in the target platform 208 (computer system). That is,dynamic environmental condition 208 is defined as environmentalconditions such as temperature, device status, load, etc. in thecomputer system, software policy (business logic, identity, servicelevel agreement), legacy software, or other dynamic characteristics ofthe computer system. Thus, the present invention can be used tonormalize platform management interfaces, integrate legacy platformmanagement interfaces, or to control platforms based on dynamiccharacter4istics of the environment or platform.

Second, script 210 may be any software code, but in a preferredembodiment, as described in detail below, script 210 is a script thatcalls a particular utility or procedure responsive to the data in theXML source 204.

With reference then to FIG. 2 b, an exemplary example of how thecomponents in FIG. 2 a may function is shown. For purposes ofillustration, assume that XML source 204 is an XML-RPC packet checkingon target platform 200 to make sure that target platform 200 is notrunning too hot. Thus, the XML-RPC pseudocode in XML source 204 shown inFIG. 2 b asks if target platform 200 is running too hot, and if so, totake corrective steps. XSL stylesheet 206 shows pseudocode for checkingthe temperature of target platform 200, and if too hot, either turningon a fan or, if the fan is not working, turning off a processor. Dynamicenvironmental conditions 208, which is a second XSL stylesheet unlessXSLT processor 202 has been modified to accept other direct input ofdynamic environmental conditions 208, is called by XSLT processor 202 torun XSL stylesheet 206. Since the fan is broken, as described by dynamicenvironmental conditions 208, then a Perl script 210 is issued invokinga utility (not shown) in target platform 200 to turn off a processor(also not shown) in target platform 200.

With reference now to FIG. 3, additional steps to those exemplified inFIG. 2 a are shown. As in FIG. 2 a, a management application 302 sendsan XML-RPC source document 304 to a target platform 200. The XML-RPCsource document 304, together with an XSL stylesheet 306 andenvironmental/dynamic conditions 308 (of target platform 200) areprocessed in XSLT processor 310 a to create a Perl script 312 thatinvokes a resource manager, such as a call to a function that enacts theunderlying instruction found in XML-RPC source document 304.

Note that the XML-RPC specification supports feedback. That is, XML-RPCnot only allows management application 302 to send instructions via anXML-RPC source document 304 to the XSLT processor 310, but XML-RPC alsoallows management application 302 to receive an XML-RPC responsedocument 314 that informs management application 302 what actionsoccurred at target platform 200 in response to the receipt of theXML-RPC source document 304. To generate the XML-RPC response document314, XSLT processor 310 b (which preferably is the same XSLT processoras XSLT processor 310 a) transforms the Perl script 312 under directionsdictated by the environmental/dynamic conditions 308 of target platform200, which now include the status of target platform 200 after theaction (such as turning off a processor) invoked by Perl script 312. Theresponse document 314 is then sent back to management application 302.

While the example shown in FIG. 3 is relatively simple for illustrativepurposes, it demonstrates how the present invention using a new XML-RPCinterface can be dynamically bound to an existing software componentusing only two test files (XML-RPC source document 304 and XSLstylesheet 306) and an XSLT processor 310.

While the invention has been shown in an exemplary manner as creating aPerl script, note that, as shown in FIG. 4, XSLT processor 202 cangenerate any type of code, including a C Source file 402, which, whenfed through a C compiler such as gcc-odynamic source.c 404, can generatebinary executable code 406, which can be executed with arguments usingthe execvp 408 function call.

With reference now to FIG. 5, the present invention can also be used tonormalize interfaces between legacy applications, such as IBM Director™and RMC (Resource Management and Control). That is, an XSLT processor502 can have access to an XSL stylesheet 504 that is unique for IBMDirector™ and an XSL stylesheet 506 that is unique for RMC, amulti-platform supporting control application. When an XML-RPC sourcedocument 508 is received while under the influence ofenvironmental/dynamic conditions 510 of the target platform (not shown),then the XSLT processor 502 may create either a Visual Basic script 512that invokes IBM director™ or a Perl script 514 that invokes RMC. Thatis, the XSLT processor 502 is programmed with intelligence thatrecognizes, based on the current environmental/dynamic conditions of thetarget platform, which stylesheet should be used, based on the hardware,operating system, and other features currently on the target platform.

FIG. 6 is a flow chart of exemplary steps taken with the features shownin FIG. 5. After initiator block 602, the target platform receives anXML-RPC source document (block 604). The XML-RPC source document isevaluated by the XSLT processor in light of the current dynamicenvironmental conditions of the target platform (block 606). In responseto this evaluation, the XSLT processor selects the appropriatestylesheet (block 608), creates appropriate script based on thestylesheet that was selected (block 610), and the process ends(terminator block 612).

With reference now to FIG. 7, there is depicted a block diagram of adata processing system in which a preferred embodiment of the presentinvention may be implemented. Data processing system 700 represents anexemplary hardware configuration of a target platform. Data processingsystem 700 may be, for example, one of the models of personal computersor servers available from International Business Machines Corporation ofArmonk, N.Y. Data processing system 700 includes a central processingunit (CPU) 702, which is connected to a system bus 708. In the exemplaryembodiment, data processing system 700 includes a graphics adapter 704also connected to system bus 708, for providing user interfaceinformation to a display 706.

Also connected to system bus 708 are a system memory 710 and aninput/output (I/O) bus bridge 712. I/O bus bridge 712 couples an I/O bus714 to system bus 708, relaying and/or transforming data transactionsfrom one bus to the other. Peripheral devices such as nonvolatilestorage 716, which may be a hard disk drive, and input device 718, whichmay include a conventional mouse, a trackball, or the like, is connectedto I/O bus 714.

The exemplary embodiment shown in FIG. 7 is provided solely for thepurposes of explaining the invention and those skilled in the art willrecognize that numerous variations are possible, both in form andfunction. For instance, data processing system 700 might also include acompact disk read-only memory (CD-ROM) or digital versatile disk (DVD)drive, a sound card and audio speakers, and numerous other optionalcomponents. All such variations are believed to be within the spirit andscope of the present invention.

It should be understood that at least some aspects of the presentinvention may alternatively be implemented in a program product.Programs defining functions on the present invention can be delivered toa data storage system or a computer system via a variety ofsignal-bearing media, which include, without limitation, non-writablestorage media (e.g., CD-ROM), writable storage media (e.g., a floppydiskette, hard disk drive, read/write CD ROM, optical media), andcommunication media, such as computer and telephone networks includingEthernet. It should be understood, therefore in such signal-bearingmedia when carrying or encoding computer readable instructions thatdirect method functions in the present invention, represent alternativeembodiments of the present invention. Further, it is understood that thepresent invention may be implemented by a system having means in theform of hardware, software, or a combination of software and hardware asdescribed herein or their equivalent.

The present invention thus uses XML data transformation techniques toallow the dynamic linking of software components based on runtimefactors such as environmental conditions (temperature, device status,load), policy (business logic, identity, service level agreements), andother dynamic characteristics of the target platform or host. Suchdynamic linking can allow an interface invocation t link to differentunderlying software components in different manners, based on thedynamic environmental factors of the target platform. When combined withlate binding, this will increase the flexibility of software components.Thus, the actual interface binding can then be performed based onenvironmental conditions, policy, or other dynamic characteristics ofthe platform or host.

While the invention has been particularly shown and described withreference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, while one preferred embodiment has been described as usingthe XML-RPC format/protocol, alternatively a Simple Object AccessProtocol (SOAP)/Web Services Descriptor Language (WSDL) mechanism can beused with the described XML/XSLT mechanism. (The specification for SOAP,which is herein incorporated by reference in its entirety, is referencedin “W3C Candidate Recommendation—SOAP Message Transmission OptimizationMechanism”, published by W3C on 26 Aug. 2004. The specification forWSDL, which is herein incorporated by reference in its entirety, isreference in “W3C Working Draft—Web Services Descriptor Language (WSDL)Version 2.0, published by W3C on 3 Aug. 2004.) That is, the presentinvention is particularly useful when working with any RPC mechanismthat is based on XML.

1. A method comprising: inputting an Extensible Markup Language (XML)document and an Extensible Style Language (XSL) stylesheet into anExtensible Style Language Transformations (XSLT) processor; andoutputting an output script from the XSLT processor to a target platformbased on a dynamic environmental condition of the target platform, thetarget platform being a combination of hardware and software in acomputer system.
 2. The method of claim 1, wherein the dynamicenvironmental condition of the target platform is used to select the XSLstylesheet.
 3. The method of claim 1, wherein the dynamic environmentalcondition of the target platform is entered into the XSLT processorseparate from the XSL stylesheet.
 4. The method of claim 1, wherein theXSLT processor selects the XSL stylesheet from a plurality ofdifferently formatted XSL stylesheets.
 5. The method of claim 4, whereinthe differently formatted XSL stylesheets include an XSL stylesheet forIBM Director and an XSL stylesheet for Remote Management and Control(RMC).
 6. The method of claim 4, wherein the XSLT processor selects theXSL stylesheet from a plurality of differently formatted XSL stylesheetsaccording to which type of output script is needed by the targetplatform.
 7. The method of claim 6, wherein the needed output scriptdepends on the dynamic environment condition of the target platform. 8.A method comprising: generating, in a management application, anExtensible Markup Language—Remote Procedure Calling (XML-RPC) sourcedocument; inputting the XML-RPC source document and an Extensible StyleLanguage (XSL) stylesheet into an Extensible Style LanguageTransformations (XSLT) processor; outputting an output script from theXSLT processor to a target platform, the target platform being acombination of hardware and software in a computer system, based on anenvironmental condition of the target platform, the output script beinga script capable of invoking a resource manager in a Resource Managementand Control (RMC) program; using the XSLT processor, the output script,and the environmental conditions to generate an XML-RPC responsedocument; and transmitting the XML-RPC response document to themanagement application, wherein the XSLT processor is able to use thesame environmental conditions to create a feedback response informingthe management application as to what action has been taken in thetarget platform in response to the XML-RPC source document.
 9. A methodcomprising: inputting a source document into a software code generator;and outputting software code from the software code generator to atarget platform based on an environmental condition of the targetplatform.
 10. The method of claim 9, wherein the environmental conditionof the target platform determines which of a plurality of stylesheets isused by the software code generator to generate the outputted softwarecode.
 11. The method of claim 9, wherein the software code generator isan Extensible Style Language Transformations (XSLT) processor.
 12. Themethod of claim 11, wherein the software code being outputted from theXSLT processor is a Perl script.
 13. The method of claim 11, wherein thesoftware code being outputted from the XSLT processor is a script thatis capable of invoking a utility in the target platform.
 14. The methodof claim 13, wherein the utility is capable of correcting a defect inthe target platform.
 15. The method of claim 11, wherein the softwarecode being outputted from the XSLT processor is a C Source file.
 16. Acomputer program product, residing on a computer usable medium,comprising: program code for inputting a source document into a softwarecode generator; and program code for outputting software code from thesoftware code generator to a target platform based on an environmentalcondition of the target platform.
 17. The computer program product ofclaim 16, wherein the environmental condition of the target platformdetermines which of a plurality of stylesheets is used by the softwarecode generator to generate the outputted software code.
 18. The computerprogram product of claim 16, wherein the software code generator is anExtensible Style Language Transformations (XSLT) processor.
 19. Thecomputer program product of claim 18, wherein the software code beingoutputted from the XSLT processor is a script that is capable ofinvoking a utility in the target platform.
 20. The computer programproduct of claim 19, wherein the utility is capable of correcting adefect in the target platform.
 21. A method comprising: generating, in amanagement application, a Simple Object Access Protocol/Web ServicesDescription Language (SOAP/WSDL) source document; inputting theSOAP/WSDL source document and an Extensible Style Language (XSL)stylesheet into an Extensible Style Language Transformations (XSLT)processor; outputting an output script from the XSLT processor to atarget platform, the target platform being a combination of hardware andsoftware in a computer system, based on an environmental condition ofthe target platform, the output script being a script capable ofinvoking a resource manager in a Resource Management and Control (RMC)program; using the XSLT processor, the output script, and theenvironmental conditions to generate a SOAP/WSDL response document; andtransmitting the SOAP/WSDL response document to the managementapplication, wherein the XSLT processor is able to use the sameenvironmental conditions to create a feedback response informing themanagement application as to what action has been taken in the targetplatform in response to the SOAP/WSDL source document.